The invention relates generally to access governance systems that use roles to grant access and entitlements to users, and more specifically to a system and method for reviewing the accuracy of role definitions.
In general, access governance systems define a user's access rights and entitlements. A role is an object that associates some number of people or identities with a common set of access rights or entitlements. Roles have become a common tool to simplify how people talk about access rights. For example, a user may have read/write access to a source control system, the ability to work on issues in a defect tracking system, and read/write access to the engineering folder on the corporate file share. If we define a role called “software engineer” and associate all of those entitlements with that role, we can simply say that person has “software engineer” access. Not only does that simplify the description of their access rights, but giving that role a descriptive name (“software engineer”) provides business or functional context.
Roles present an opportunity to create a common and mutually understandable language of access between business and IT. When representatives from business and IT collaborate on the development of roles, they define a common vocabulary they can use to properly manage and govern user entitlements. The business users can associate users with these roles to provision or explain their entitlements based on their job function, location, or project assignments. Its view of a user's access becomes simpler to understand and more meaningful because their role aligns with how business users think about people within the organization. IT associates entitlements with these roles, making it easier to ensure that only appropriate access is granted.
Another important aspect of roles is that while a role has a collection of users and an associated collection of entitlements, this association really describes a user's authorized entitlements and not necessarily their actual ones. This notion of “authorized” versus “actual” entitlements is important for any roles lifecycle solution. Ideally the assignment of a role is tightly linked to the automatic provisioning of their authorized entitlements. But holding a role just authorizes the user to be granted those entitlements. Being assigned a role does not in and of itself mean a user has been granted the underlying entitlements, nor does it change how the underlying application authorizes an individual to use those entitlements.
There are two types of roles, business and technical, each designed to address different ways of simplifying the view of user access.
Business roles are aligned around a person's relationship to the organization, are most commonly associated with job titles or job codes and are often referred to as job roles. Similarly, project roles are business roles that are associated with various projects within the organization. Business roles may also be aligned with other criteria such as location, workflow or organization. The benefit of business roles is that they can be easily associated with employees based on their function or “role” within the organization. These business roles make it easy to enable access for new employees or to adjust existing employees' access as they change job functions or the work they are doing. Finally, aligning business roles with a person's functions and responsibilities simplifies and increases the accuracy of a manager identifying inappropriate access during entitlement reviews and granting new access as required.
Technical roles help abstract the implementation of business functions from the IT infrastructure. They allow the entitlements granted to a business role or a user to remain constant even when the underlying applications or technology that provide those capabilities changes. In addition, they hide the technical details of a function and refer to it in more readily understandable terms. For example, it is easy to understand the function named “purchase order approver” even if that technical role is associated with very technical entitlements not easily understood by business users. The existence of the role means those technical details can largely be ignored by the business user. Similarly, if the purchasing application or infrastructure changes, the details of the role can be changed without requiring the business to change its view of the user's entitlements.
As discussed above, the main purpose of roles is simplifying how we describe user access. This simplification is beneficial in many ways when it comes to access governance. First, entitlement reviews are simplified (and made more accurate) when there are fewer entitlements to review and those entitlements are easier to understand. If roles were not available, a reviewer would have to examine all of their users' granular entitlements, many of which would be described in technical, hard to understand terms. This would make it more difficult to determine if the entitlements are appropriate, raising the risk that a reviewer will leave an entitlement in place if they do not understand it, in fear that removing it would make it impossible for the person to do their job. Introducing roles into the process consolidates the entitlements required for their job functions into applicable roles, makes the review decision easier, and allows reviewers to focus on those entitlements not covered within roles.
One of the major causes of inappropriate access is people carrying entitlements from job to job as they move within a company. Access governance solutions can help automate the detection of such “movers”. When used in combination with roles, this is a very effective means for ensuring that a user's access is adjusted as they move. Business roles, as opposed to technical roles, are useful because they are associated with the user's business context and often are directly associated with their specific function. As their functional responsibilities change, the access required for that function can be easily granted to them. Similarly, these same associations of roles to business context can be used to automatically grant appropriate access to people joining the company.
Another problem with existing access governance systems is that audits commonly find users who have conflicting access rights and entitlements. For example, an audit may find a finance clerk with access to both the accounts receivable and accounts payable modules of an enterprise resource planning (ERP) system. These entitlements would allow the clerk to single-handedly create and pay a purchase order, which violates segregation of duties policies. While it is very difficult and time consuming to detect such violations on a per-user basis, using a job role to define all the entitlements a user should have to perform his or her job makes it much easier to enforce proper segregation of duties. All that is required is checking roles against each other and making sure that each role contains no conflicting privileges. Users are less apt to have segregation of duties issues in this model as their roles should be aligned with their current job function.
Roles also make it much easier to provide users with new access rights. In addition to the access users should automatically be given based on their job function, organizations can also define project roles that describe the temporary access users may need for specific projects. When people need to be added to a project, they can simply be given the access rights defined by the appropriate project role. Without these roles, determining the access needed for a particular user joining a project can be error-prone and often inefficient, and the additional access is often not removed when they leave the project.
Technical roles help ensure the appropriate access is granted without having to understand the technical details of enabling that access. For example, requesting a technical role of “purchase order approver” is much more straightforward than having to understand the specific application entitlements, storage entitlements, etc. that a user may need to perform that simple function.
In much the same way roles help simplify how people request access, they help in the full lifecycle of access management. Approving access requests becomes simpler because in many ways the role defines a purpose or justification for the access being requested. Supervisors looking at their employees' access can more easily identify inappropriate access a user may have when it is organized into roles, as they may notice roles that no longer match a person's responsibilities.
For each of the benefits outlined above, the benefit can only be realized to the extent that the roles deployed in the system are accurate, i.e. to the extent that the roles have the correct members and contain the correct entitlements, where “correct” is with reference to the business purpose of the role, and where it is possible to easily determine that business purpose.
Reviews are only truly made simpler, for example, if the roles each user has are accurate, and meaningful to the reviewer, and the entitlements that being in those roles grants the user make sense for the business purpose of the role. For example, if a manager who is reviewing an employee who the manager know has thousands of entitlements, and only sees a dozen roles, the review will go much faster so long as the manager can trust that by approving the roles, the manager is approving the right set of entitlements “under the covers”. If the manager cannot tell what a particular role is for or about by the name and/or description of the role, then the manager has to drill into it and start looking at individual entitlements. If the manager can tell what the role is supposed to be for, but the manager does not trust that it has the right contents, then the manager also has to start drilling into individual entitlements. As soon as a manager has to start drilling into the roles to see what entitlements are in them, the manager starts to lose the benefits of compressing the entitlement space into roles. The same is true for approvals, requesting access, and creating automated processes for movers, leavers, segregation of duties, etc.
Since all the benefits of roles are realized in proportion to the extent to which the definitions of the roles are accurate, and both meaningful and trusted by the users of those roles, what is needed then is a role review process to make sure that those role definitions accurate and meaningful, and to ensure that they stay that way, or even improve. Such a process would naturally foster user trust in the definitions.